Computerized systems provide many advantages towards peoples' ability to perform tasks. Indeed, the computer system's ability to process information has transformed the way we live and work. Computer systems now commonly perform a host of tasks (e.g., word processing, scheduling, database management, etc.) that prior to the advent of computer systems were preformed manually.
Computing systems now take a wide variety of forms including desktop computers, laptop computers, tablet PCs, Personal Digital Assistance (PDAs), and the like. Even household devices (such as refrigerators, ovens, sewing machines, security systems, and the like) have varying levels of processing capability; and thus may be considered computing systems. Processing capabilities continue to be incorporated into devices that traditionally did not have such processing power. Accordingly, the diversity trend of computing systems will likely increase.
Even more recently different computing systems have been coupled together to form computer networks over which the computer systems can communicate electronically to share data. As a result, many of the tasks preformed at a computer system (e.g., accessing electronic mail, web browsing, etc.) include electronic communication with one or more other systems via a computer network (e.g., the Internet).
Often, electronic communication on a computer network includes a client computer system (hereinafter referred to as a “client” or “device”) requesting access to a service (e.g., electronic mail or a web server) at a server computing system (hereinafter referred to as a “server” or “service”). Before granting the client access to the service, the server may issue a challenge to the client requiring the client to prove its identity to the server. Such authentication processes are typically preformed using a basic scheme, which requires the user credentials, e.g., username and password, to be presented to the server. Once authenticated, the user is given authorization, which allows the user access to various resources based on the user's identity.
Although credentials such as a username and password allow for a relatively simple challenge, there are several security risks that have emerged with such authentication. For example, when the username and password go over the wire, if they are not encrypted, hacks or other rogue clients may gain access to the credentials and use them in malicious ways. Further, these credentials are delegable by default, which means that once the client authenticates through one server, the client typically has access to all servers within the network. In addition, these credentials are typically stored on the device so that user does not to have to continually remember a multitude of usernames and passwords. This, however, represents a big security issue for devices that can easily be lost and/or stolen (e.g., PDAs, cellular phones, laptop computers, etc.).
In order to overcome some of the disadvantageous of password credentials, public key infrastructures have been developed. These systems enable users of basically unsecured public networks such as the Internet to securely and privately exchange data through the use of a public and private cryptographic key pair that is obtained and shared through a trusted authority. The public/private key pair infrastructure also provides for digital certificates that can identify an individual or an organization and directory services that can store and, when necessary, revoke the certificate.
Typically, a public key infrastructure consists of: (1) a Certificate Authority (CA) that issues and verifies digital certificates, which includes the public key or information about he public key; (2) a Registration Authority (RA) that acts as the verifier for the certificate authority before a digital certificate is issued to a requester; (3) one or more directories where the certificates (with their public keys) are held; and (4) a certificate management system. Of course, other topologies for public key infrastructures are also available, but the aforementioned entities are some of the basic building blocks used in most systems.
In public key cryptography, a public and private key are created simultaneously by a CA using an algorithm. The private key is given only to the requesting party and the public key is made publicly available (as part of a digital certificate) in a directory that all parties can access. The private key is never shared with anyone or sent across the Internet. For privacy purposes, a client can use the private key to decrypted text that has been encrypted with its public key by another computing device that has access to the public key through a public directory.
A client can also use the public/private key infrastructure to authenticate itself to a server using a similar challenge and response previously described with regard to username and password. In this instance, however, a server can create and store a random blob of data, which it then provides to the client as part of the challenge. The client uses its private key to encrypt the blob of data, which it returns to the server. A CA then decrypts the blob and compares it to the original data. If they match, the client is authenticated and allowed access to the service in accordance with its authorization.
Although digital certificates have become a primary means for encryption and authentication, due to infrastructure topology changes there have emerged several shortcomings and downfalls with using them. For example, more and more networks are using front-end servers to provide most of the functionality for accessing services such as email, while back-end servers are used to simply store the data. As such, the front-end service acts as a load balancing device for the back-end such that there can be several front-end services acting on behalf of a host of clients, yet only a single back-end server is used to access and store data for all of the clients. Note, however, that a client must now authenticate themselves to both servers in order to gain access to each one.
When a username and password is used as credentials, this topology does not pose a problem since, as previously mentioned, such credentials are delegable by default. Digital certificates, on the other hand, are non-delegable by default since each challenge from each server will be different, i.e., different data blobs are encrypted. In an attempt to rectify this and other deficiencies, some systems provide for a general delegation that allows the client to authenticate using a certificate at one server and then allow access to all other servers within the network. As can be seen, however, this posses another security risk and has some of the same shortcomings of a password, i.e., it allows full access to the network. Accordingly, the same concerns arise for mobile device that use certificates in a general delegation infrastructure.
To combat the concerns of general delegation, another topology has emerged known as constrained delegation. In this infrastructure, delegation is limited to a predefined set of servers within the network. Although this a great improvement over general delegation systems, constrained delegation topologies also have there shortcomings. For example, these infrastructures are very complex and require a high degree of skill to appropriately configure. Further, many systems require use of the same versioning of software and/or hardware for each of the servers within the network. Commonly, however, systems have mixed configurations, and thus will not be able to use constrained delegation. In addition, constrained delegation requires a two-way trust between the delegable servers. Accordingly, resource forests with only a one-way trust cannot take advantage of this feature.